セキュリティ運用って包括的にできていますか?SaaSを使って次のステップへ【資料公開】- Classmethod Cloud Security Fes.

セキュリティ運用って包括的にできていますか?SaaSを使って次のステップへ【資料公開】- Classmethod Cloud Security Fes.

Classmethod Cloud Security Fes. で発表した資料の公開と発表内容についての補足説明をします。
Clock Icon2024.11.25

11/21(木)にクラウドセキュリティの最新情報を学ぶ1日として、Classmethod Cloud Security Fes. がオンラインで開催されました。

本イベントの全体概要はこちらになります。
https://classmethod.jp/m/cloud-security-fes/2024/

ご参加いただいたみなさまありがとうございます。

私は2番目のセッション「セキュリティ運用って包括的にできていますか?SaaSを使って次のステップへ」で登壇させていただきました。
発表の際の資料を本ブログにて公開いたします。

補足内容を本ブログでご紹介させていただきます。

資料

セッション概要

AWSのベストプラクティスから学ぶセキュリティの一つに「検出」というカテゴリがあります。「検出」を強化するために、AWSのどんなサービスを使って、何が強化できるかを整理します。
AWSサービスで「検出」を強化した時の課題感に触れつつ、SaaSを使った課題解決と、Splunk Cloud の機能や特徴についてご紹介します。

AWS Well-Architcted フレームワーク

Screenshot 2024-11-25 at 15.22.17.jpg

AWSには、AWSアーキテクチャを設計する上でベストプラクティスをまとめたフレームワークがあります。
AWS Well-Archited フレームワークは、7つの柱で構成され、そのうちの「セキュリティ」の項目では、「検出」というカテゴリについてのベストプラクティスが紹介されています。

AWS Well-Architected フレームワーク「検出」についての公式ドキュメント参考:
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sec-detection.html

AWS Well-Architected フレームワーク「検出」の「質問とベストプラクティス」公式ドキュメント参考:
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sec-04.html

AWSの「検出」を強化するログ

Screenshot 2024-11-25 at 15.55.04.jpg

「検出」を行うには、ログが必要。
ログは「セキュリティ監視」、「フォレンジック調査」、「法的要件」、「コンプライアンス監査」のために利用されます。
AWSにおいても、さまざまなログがあり、利用しているサービスごとでその対象は異なってきます。
その中でもセキュリティ上重要とされているログとして、代表的なものは AWS CloudTrail の監査ログですが、下記のログも多くの場合重要とされます。
また、運用(提供)しているサービスのアプリケーションのログやOSのログなども、システムへのアクセスログや認証ログなどが含まれれている場合は、これらのログも非常に重要です。

  • AWS CloudTrail
  • Amazon VPC フローログ
  • Amazon Route53 リゾルバログ
  • Elastic Load Balancing ログ
  • AWS WAF ログ
  • EC2、アプリケーションログ
  • など

また、AWSのセキュリティサービスから出力されるアラートもログとして扱い、上記のログとユーザーやホスト、IPアドレスなどのエンティティと相関付けをすることが大事です。
重要なAWSセキュリティサービスからのログは以下のようなものがあります。

  • AWS Config
  • Amazon GuardDuty
  • AWS Security Hub
  • Amazon Macie
  • Amazon Inspector
  • など

ログは闇雲に収集してしまうと、どんどん増えてしまうので、セキュリティ上重要なログや、サービス提供にかかせない重要なログをきちんと事前に定義して、必要なものに絞ることも大事なポイントです。

「検出」においてのログソースとしてのAWSサービスについて確認しました。

Screenshot 2024-11-25 at 15.36.21.jpg

AWSの「検出」を強化するログ保管と正規化

Screenshot 2024-11-25 at 15.56.04.jpg

次のステップでは、信頼性の高いストレージへのログ保管と、後続のログの活用の効果を最大化するために正規化の作業が重要です。
AWSサービスでは以下のようなサービスでサポートすることができます。

  • Amazon S3(ログの保存)

    • 安価で信頼性が高い
    • ストレージクラスを使って、コスト最適化
  • AWS Glue(正規化)

    • ETL処理を行うマネージドサービス
  • Amazon Security Lake(ログの保存 + 正規化)

    • セキュリティに関連するデータの保管と正規化
    • OCSF形式にフィールドは抽出され正規化される

Amazon Security Lake の補足になりますが、OCSF(Open Cybersecurity Schema Framework)とは、異なるセキュリティツール間のデータ形式を標準化するための共通のデータフォーマットになります。
データ形式の標準化(正規化)を行うことで、異なる複数のデータソースに対して、同じフィールド名で検索・分析ができるようになります。

OCSF参考:
https://github.com/ocsf

Security Lake の概要についての参考:
https://dev.classmethod.jp/articles/amazon-security-lake-ga/

Screenshot 2024-11-25 at 21.59.41.jpg

複数のAWSアカウントを利用している場合などは、複数のアカウント間のデータを集約するための機能や、データ保管要件などのガバナンス統制が必要になってきます。
その場合は、AWS Organizations が有効です。

AWSの「検出」を強化するログの活用

Screenshot 2024-11-25 at 22.03.03.jpg

ガバナンス統制されたログ保管までは実現したが、ログの活用まで至らず、そもそもやりたかったこと(目的)を果たせていない、という課題はありがちなことです。
ログ活用について、3段階の活用に分けて表現してみると、ログ分析・ログの可視化・セキュリティ監視とし、下から上に向かってリアルタイムでの処理が必要な項目とすることができます。
特にセキュリティ監視では、リアルタイム性の高い可視化や分析を必要とし、複数のログソースから脅威(攻撃の根拠や進行中のイベント)の検出をするための機能と位置づけます。

Screenshot 2024-11-25 at 22.09.03.jpg

そして、ログの活用を実現するためのAWSサービスを当てはめてみました。

それぞれのAWSサービスの使い所や、手の届かないところを筆者なりの観点でまとめました。

Screenshot 2024-11-25 at 22.10.20.jpg

Screenshot 2024-11-25 at 22.10.31.jpg

Screenshot 2024-11-25 at 22.10.38.jpg

Screenshot 2024-11-25 at 22.10.50.jpg

AWSのネイティブサービスのみで検出強化した時の課題

以下のような課題が考えられます。

Screenshot 2024-11-25 at 22.14.24.jpg

SaaSによる解決と Splunk Cloud

SaaSは、ソフトウェア機能だけを利用することができるので、インフラ基盤の運用が必要ない、という大きなメリットを享受することができます。

また、特定の分野に特化した機能を有しているために、使い始めから利用可能な作り込みがされていたり、ベンダーロックインを回避する、ベストオブブリードの考え方で、良い者同士をうまく統合できることが主な強みとして挙げられます。

Screenshot 2024-11-25 at 22.18.30.jpg

SaaS の中でも、Splunk Cloud は SIEM の分野で非常に優れた機能を持っていて、先程挙げた課題に対するソリューションを提供しています。

Screenshot 2024-11-25 at 22.20.19.jpg

AWSだけでなく「検出」を組織全体で強化することができ、ログの保存〜アラーティングまで、さまざまなログソースを扱うことができます。

Screenshot 2024-11-25 at 22.22.23.jpg

ログの収集では構造化データ・非構造化データ問わず、様々なログを取り扱えますし、AWSを含む3大クラウドのデータは Data Manager を使って、簡単に取り込み設定を行うことができます。

AWSの Data Manager 利用方法は下記のブログをご参考ください:
https://dev.classmethod.jp/articles/data-manager-splunk-cloud-sakuma-1/

正規化では、CIM(Common Information Model)というデータ標準化のフォーマットを採用していて、Add-on をインストールするだけで、異なるセキュリティツールを同じ観点で分析することができるようになり、ログ活用を最大化することができます。

CIM の概要や利用の仕方については下記のブログをご参考ください:
https://dev.classmethod.jp/articles/splunk-cim-sakuma-20240322/

CIMを有効活用した、マルチクラウドの可視化も簡単に実現することができます。

Screenshot 2024-11-25 at 22.33.02.jpg

InfoSec Multicloud App の利用方法や分析方法については以下のブログをご参考ください:
https://dev.classmethod.jp/articles/slug-GemWNOzBtDWe/

Amazon Security Lake のサブスクライバーとして Splunk Cloud を利用することも可能です。
Amazon Security Lake では OCSF をログの標準化フォーマットとしてサポートしていますが、Splunk は CIM をログの標準化フォーマットとしています。
当然、異なる標準化フォーマットが2つあっては、標準化の意図とするメリットが得られませんが、Splunk では2つの標準化フォーマットが共存できる仕組みを持っています。

Screenshot 2024-11-25 at 22.39.29.jpg

一つは、Splunk 内で OCSF を扱うための分析ルールが利用可能であること。

Screenshot 2024-11-25 at 22.40.36.jpg

Splunkの分析ルールはこちらで検索することができます:
https://research.splunk.com/

もう一つは、Splunk 内に取り込んだ OCSF データを CIM に変換し直す、Add-onがあること。
CIMに変換し直すことで、Splunk がサポートしてきた CIM 対応の App が利用可能になります。

Screenshot 2024-11-25 at 22.40.50.jpg

Amazon Security Lake をサブスクライバーとした場合でも、異なるデータフォーマットのコンフリクトを無くすことで、強力なログ活用能力を損なうことなく、データレイクを柔軟に選択することが可能となります。
つまり、あらゆる場所にあるデータを分析すること(データレイクの分散化)ができるようになります。

まとめ

「検出」を強化するための手段について整理し、強化を実現するためのAWSサービスそれぞれの使い所について理解いただけたかと思います。
また、「検出」強化のために SIEM 製品を検討する時の目安として、「セキュリティ監視を実現したいこと」や複数のAWSサービスを組み合わせて目的を達成する複雑性「ビルディングブロックを解消して目的を達成したいこと」、を基準に考えていただくのがいいかと思います。
さらに組織全体の「検出」強化を考えた時に、オンプレミスやマルチクラウドをカバーするハイブリッド性とベンダーロックインを回避するソリューションを選択することが良いのではないでしょうか。

宣伝

12/3 (火) 11:00 - 12:00 にて Splunk Cloud を題材とした単体ウェビナーを企画しております。
お時間の都合が合う方はぜひ、ご参加ください。

Screenshot 2024-11-26 at 8.52.36.jpg

https://events.classmethod.jp/seminar/f0fd6812-fd84-41a4-bfcc-d7b7b677b8e2/

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.